Subject: [sidr] Comments on draft-ietf-sidr-res-certs-11.txt

From: "David A. Cooper" <[email-masked]>
Date: Fri, 29 Aug 2008 09:39:19 -0400

Below are my comments on draft-ietf-sidr-res-certs-11.txt.  I understand 
that WG LC was just canceled, and that a new draft will be coming out 
soon, but I don't think that any of my comments will be affected by the 
impending changes.

1) Section 3 states:

     Unless specifically noted as being OPTIONAL, all the
     fields listed here MUST be present, and any other field
     MUST NOT appear in a conforming Resource Certificate.

  This seems overly constraining. There should be no need to prevent
  the inclusion of additional extensions as long as they are marked
  non-critical.

2) Sections 3.3 and 4.5: For consistency, the profile should either 
permit the use of SHA-1 or forbid the use of 1024 bit keys.  Also, the 
second paragraph of section 3.3 should be deleted, since the same text 
already appears in section 3.8, and section 3.3 does not mention 
anything about key sizes.

3) Section 3.9.5 states:

     In this profile, the scope of the CRL is specified to be all
     certificates issued by this CA issuer using a given key pair.

  The scope of a CRL MUST be all certificates issued by the issuing CA
  unless the CRL includes an issuingDistributionPoint extension.  So, if
  the scope of CRLs is to be limited to certificates signed with a given
  key pair, then the profile must either require inclusion of the
  issuingDistributionPoint extension in CRLs or forbid CAs from performing
  key rollover. The latter option may be implemented by having issuers
  change names whenever changing the key pair used to sign certificates.

4) Section 4.6.2 should say that revocation date "MUST NOT be a future 
date."  The revoked certificates list cannot be used to list 
certificates that are not yet revoked, but that will be revoked in the 
future.

5) Section 5.1.1 (and several other places): The draft repeatedly states 
that subject names must be "unique per issuer in certificates issued by 
this issuer." While this is true, it may be misleading since it is a 
necessary, but not sufficient condition.  X.509 requires that names be 
globally unique, so issuer and subject names must be unique within the 
scope of the entire RPKI.

6) The following two paragraphs in Section 5.3 (under BasicConstraints) 
seem inconsistent:

       If this is omitted then the CA will issue an end entity
       certificate with the BasicConstraints extension not present in the
       issued certificate.

       The CA MAY honour the SubjectType CA bit set to off (End Entity
       certificate request), in which case the corresponding end entity
       certificate will not contain a BasicConstraints extension.

   If failure to specify a SubjectType CA bit value always results
   in the issuance of an end entity certificate, why would it be
   acceptable for a CA to issue a CA certificate if the subject
   specifically requests an end entity certificate?

7) Section 5.3 (under SubjectInformationAccess):  This section states 
that the certificate request for an EE certificate MUST include the SIA 
extension if the "EE certificate is intended for use in verifying 
multiple objects" or the "EE certificate is used to sign a single 
object". However, Section 3.9.7 states that inclusion of an SIA 
extension in EE certificates is optional (under some circumstances). 
Under what circumstances (if any) is it not a requirement to include an 
SIA extension in an EE certificate?

8) Section 6.3: Steps 2 and 3 seem unnecessary. Including these steps 
would seem require the use of path validation software that has been 
customized to only validate RPKI certificates rather than allowing for 
the use of off-the-shelf path validation software. What is the 
compelling reason for including these checks?

9) "certificate authority" should be replaced with "certification 
authority".

10) "Certificate Practice Statement" should be replaced with 
"Certification Practice Statement".

11) "certificate path" should be replaced with "certification path".

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr