[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Peter:
Some more remaks:
1 ***
text says:
1.3. Abstract Syntax Notation
All X.509 certificate [X.509] extensions are defined using ASN.1
[X.660].
and:
[X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
this looks strange to me. The encoding rules are not the asn1 syntax.
Suggestion:
remove 1.3 and the reference.
I have heard from Peter Sylvester and Peter Gutmann on this point. Anyone
else have an opinion?
2 ***
If a certificate contains a key usage extension, the KeyUsage bits
that are needed depends on the EAP method that is employed; however,
the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
method end entity certificates.
This means that you cannot have a certificat WITHOUT keyUsage?
Or, in case of a certificate without keyUsage, you could use it
for CrlSigning?
No. The paragraph only talks about the key usage extension in support of
EAP methods. The question you are asking is beyond the scope of the
paragraph and the whole document.
This restriction is new, and I don't see why this is necessary.
I am not sure, but I don't know of any other purpose that has
a restriction like this, and current scvp specs don't allow to
check for this (you cannot specify MUST NOT).
The IETF (or anyone else for that matter) should not specify EAP methods
that expect either of these key usage bits to be set.
suggestion, remove the second half sentence.
3 *** chapter two should read IMO:
2. EAP Extended Key Usage Values
RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate
extension. The extension indicates one or more purposes for which
the certified public key may be used.
This specification defines two KeyPurposeId values: one for EAP over
PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP
value indicates that the certified public key is appropriate for use
with EAP in the PPP environment, and the inclusion of the EAPOL value
indicates that the certified public key is appropriate for use with
the EAP in the LAN environment. Inclusion of both values indicates
that the certified public key is appropriate for use in either of the
environments.
id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 }
id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 }
The extended key usage extension MAY, at the option of the
certificate issuer, be either critical or non-critical.
If the extended key usage is present in a certificate,
Certificate using applications MAY require that a particular purpose
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
(such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order
for the certificate to be acceptable to that application.
If a certificate contains a key usage extension, the KeyUsage bits
that are needed depends on the EAP method that is employed.
There is currently no method that require the usage of the keyCertSign
or the cRLSign bit to be set.
with the XXXX a little bit more specific.
You are primarily asking for sentence to be deleted. The sentences that you
would like to see go away are in RFC 3770, so I think that the removal
needs to be justified.
4 *** The OID arcs should be imported from
IMPORTS
id-pe, id-kp
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
id-aca FROM
PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert(12)}
This is a matter of taste. Neither approach leads to implementation issues.
Russ