[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2007-07-19 14:05:52
Message-ID: 18079.28608.900465.504502 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]

Keith Welter writes:
> Since an implementation MUST be capable of being configured to send and 
> accept the first two Hash and URL formats it's seems to follow that an 
> implementation also MUST support HTTP certificate lookup (making the 
> HTTP_CERT_LOOKUP_SUPPORTED notification extraneous).  I believe the intent 
> is for HTTP certificate lookup support to be optional but a clarification 
> to that effect would be helpful.

HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the
other end is CONFIGURED to allow HTTP lookups for the certificates.

> Assuming HTTP certificate lookup support is optional, how should an 
> implementation handle receipt of a CERT payload containing either of the 
> Hash and URL formats (or any other unsupported encoding)?  Presumably the 
> implementation should ignore the certificate payload in this case.  Is 
> that correct?

If you receive certificate payload you cannot process you can ignore
it and try to see if you can still authenticate the other end. If you
happen to have the certificate for the other end for some other reason
(preconfiguration, cached by previous session etc) then you can
authenticate the other end, if you do not have the certificate you
will fail the authentication. 

> Nit: There is a typo "syntax is for some" in the following text. 
>    Specific syntax is for some of the certificate type codes above is
>    not defined in this document.  The types whose syntax is defined in
>    this document are:
> 
> Section 3.7
> Is it safe to assume that a CERTREQ Certificate Encoding value of 12 or 13 
> implies the same thing as HTTP_CERT_LOOKUP_SUPPORTED?  If so, the 
> HTTP_CERT_LOOKUP_SUPPORTED notification would seem to be extraneous. 
> Clarification on this point would be helpful.

I would say that if you request certificates in hash and url format
then in that case HTTP_CERT_LOOKUP_SUPPORTED might have been left out,
but on the other hand if you request certificates as normal X.509
certificates, and send HTTP_CERT_LOOKUP_SUPPORTED then the other end
can send certificates either inline or as hash and url format, and in
that case the HTTP_CERT_LOOKUP_SUPPORTED is not extraneous. 

> There is a lower-case "must" in the following sentence:
>    Certificate revocation checking must be considered during the
>    chaining process used to select a certificate.
> 
> Is this "must" to be interpreted differently than an upper-case MUST?

I think that when you follow the normative reference to the base
certificate document, it is explicitly said there that certificate
revocation checking is MUST.

> This section seems to imply that it is not a protocol error for an 
> exchange to contain 1 or more CERTREQ payloads but zero CERT payloads. 
> Conversely, it seems that it is not a protocol error for an exchange to 
> contain zero CERTREQ payloads but 1 or more CERT payloads.  Is this 
> correct?

Yes. For example in the common VPN case the laptop client (initiator)
might be preconfigured to have the certificate of the SGW to be used.
In that case the initiator will only send CERT payload for his own
certificate, but does not request any certificates as he already has
certificate for the other end. And the SGW end will simply send his
CERTREQ to request the certificate from the laptop, but as SGW already
knows laptop client is preconfigured to have his certificate (and the
laptop didn't ask it with CERTREQ) he does not send his CERT at all. 
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]