[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query on draft-ietf-ipsec-pki-req-03.txt
At 07:55 AM 10/19/99 -0700, Walker, Jesse wrote:
I don't think putting a CRL source (such as an FTP or LDAP server) behind a
security gateway is the normal case. The main reason to do that is to hide
the identities of the certificates you have revoked (which might have a
business purpose). Normally, these are wide open.
The draft includes the following text in Section 2:
IKE systems conforming to this profile MUST check the
revocation statusof any certificate on which they rely, using
the algorithm described inthe PKIX certificate profile. Thus,
every conforming IKE system MUSThave a method for
receiving up-to-date revocation information for thecertificates
it is validating.
What do you intend this to mean in the remote access case? One normal
operational scenario will have the CRL distribution point the remote IPSec
host needs to validate the security gateway's certificate behind the
And, I think that "unless" is exactly right: you must use the information
In such a case, unless it has already obtained the CRL via
an alternate channel, the remote host will be unable to meet the above
I would be against that because some CRLs will be very large. In the case
of a hidden CRL DP, I'd say "you must use what you already know". I think
it is good to say "if the device knows that its CRL DP is not currently
available to the other party behind a security gateway, that device SHOULD
send its CRL".
Seemingly the best that it could be able to do is to establish
IKE and IPSec security associations, then attempt to obtain the CRL, and
then decide what to do on the basis of whether or not it could get the CRL
or the security gateway's cert gets validated. Maybe we need to require
implementations to send the latest CRL known to them during the IKE phase 1
At 08:06 AM 10/19/99 -0700, Walker, Jesse wrote:
Personally, I think it is completely lame. I would like to rip that
wholerement out of the spec. Would anyone object to me doing so? That is,
has anyone shipped an implementation that is so non-compliant that it
*requires* a non-null subject even though there's a subjectAltName?
Section 3.2 says
The subject field in IPsec certificates SHOULD be populated and
(this is contrary to the PKIX certificate profile, which says
MUST NOT be populated if the identification is in thesubjectAltName
field). The exact contents of this field are notstandardized. By
minimal subject field containscountryName and commonName.
names SHOULD be no more thanfour attribute/value pairs, each of
SHOULD be no more than 128 characters in length (these restrictions
not appear in the PKIXcertificate profile). An IKE implementation
conforms to thisprofile SHOULD NOT reject a certificate that does
Why? The rationale for this requirement is not immediately obvious.
At 12:28 PM 10/19/99 -0400, Greg Carter wrote:
Rodney and I put them in to indicate that the reader shouldn't assume that
reading the PKIX documentation literally is a good idea.
>From 1. Introduction, first paragraph:
"Note that many IPsec implementers are not completely happy with the PKIX
documents and procedures, but have agreed to use the PKIX protocols because
they are supported in other contexts and have a significant market share."
and last paragraph
"(It is noted that the fact that the two documents differ does not give
great confidence to the IPsec community or other users of the PKIX
Both of these, whether or not true, are opinions and don't really do
anything to help implementers beside adding confusion. I would suggest they
be taken out for clarity.
I agree with this. I can see many reasons why a CA would create a single
cert for an IKE system that might have multiple uses.
>From section 3.1 The extendedKeyUsage field:
"In a certificate for an IPsec end entity, the extendedKeyUsage field
commonly called "EKU") MUST be present and MUST contain only the object
22.214.171.124.126.96.36.199.2). An IKE system that conforms to this profile SHOULD NOT
accept end-entity certificates that do not follow this rule."
Why must the certificate only have the one extended key usage? This is too
restrictive. I like the idea of only having one IPSec extended key usage
bit though. Could we stick with PKIX and say that if flagged critical then
it must only have one value. Therefore you could remove the "and MUST
contain only the object identifier iKEIntermediate..." since that would be
covered by PKIX RFC 2459 section 188.8.131.52 for critical extended key usage
In Section 3.2 The subjectAltName field, last paragraph:
"The subject field in IPsec certificates SHOULD be populated and non-null
(this is contrary to the PKIX certificate profile, which says that the
subject MUST NOT be populated if the identification is in the subjectAltName
This is not true, PKIX states in section 184.108.40.206 Subject Alternative Name
Further, if the only subject identity included in the certificate is an
alternative name form (e.g., an electronic mail address), then the subject
distinguished name MUST be empty (an empty sequence), and the subjectAltName
extension MUST be present. If the subject field contains an empty sequence,
the subjectAltName extension MUST be marked critical.
The important phase being "if the ONLY subject identity included in the
certificate is an alternate name form". It does not say "If the alternate
name form is used then NO subject distinguished name may be present." which
is how I read section 3.2. For clarity I would stick with the PKIX
definitions of how subject and alternate names are to be used and remove the
And here we disagree. How are such CA's identifying an IKE system in the
subject? If you mean "kludging the IP address or DNS name into a subject
field", I have no problem saying that that MUST NOT be done in this
profile. How do others feel about this?
If ONLY the alternate name is to be used then the subject should be left
empty as PKIX states. However in practice I do not know of any
implementations that only identify the 'device' by alternate name. For
administration purposes they will always have a subject name, however there
may exist a situation where someone would like to restrict to only using the
alternate name for identification and the only way to do this is with an
Also in the last paragraph of section 3.2:
"Distinguished names SHOULD be no more than four attribute/value pairs, each
of which SHOULD be no more than 128 characters in length (these restrictions
do not appear in the PKIX certificate profile)."
Again these are too restrictive. Names in the subject/issuer are dictated
by the customers directory setup (for those using one). In practice I have
seen longer names than 4 attribute/value pairs. Length... well I don't know
much about multi char character sets but I wouldn't want to limit anything
which would prevent IPSec certificates being used in foreign languages.
I agree. I think we should take out that restriction. If the IKE system
doesn't like the cert it gets (for example, because the CA changed the
subject or subjectAltName), the system doesn't have to use that cert.
>From Appendix A:
"Regardless of the protocol used, a CA who gets an IKE system's enrollment
request that includes the subject and subjectAltName desired for the device
MUST include exactly the same subject and subjectAltName in the
certificate. If the CA does not want to issue a certificate with the same
subject and subjectAltName that was requested, the CA MUST NOT issue a
certificate with a different name and subjectAltName."
This places an unnecessary burden on the end entity to determine what
exactly its DN will be, PKIX-CMP and I think CMC both allow the CA to change
the DN that is in the request. If the device must have the exact DN then it
means a user somewhere has to type it in, very prone to failure.
is no mention of how to verify the request at the CA. The device should
generate a hash of the der encoded request and make it available to the
devices administrator for verification at the CA. Otherwise the request is
accepted without verification.
This makes sense to me, and could be part (obviously) of the out-of-band info.
This could be added. It's covered in PKIX, but yet another paragraph in the
security section is always safe...
Also mention of how to obtain the CAs keys
in a secure way, similarly usually done with a hash of the CAs der encoded
certificate. May want to add this to the security section?...
--Paul Hoffman, Director