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

From: Geoff Huston <[email-masked]>
Date: Thu, 4 Sep 2008 22:29:32 +1000

David,

Thanks indeed for taking the time to read this draft and making these  
comments. I'll respond to them  in an  interleaved style, if thats ok,  
and I should note at the outset that my WG Chair hat is OFF my head in  
this response, and I'm responding here as a co-author of the draft in  
question.

> 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.

The level of constraint taken here was quite deliberate.

We (the authors of this draft) did not want to be in the position of  
having certificates with extensions which relying parties may see as  
valid, but contain extensions that, were the replying party to  
understand the extension, would contradict or qualify in some wthis  
original validity.

We also took the position of minimialism over extensibility, taking  
the approach of nomination of a specific goal for the PKI, namely to  
construct a PKI that precisely matches the IP number resource  
allocation structure, and then defining a certificate profile that was  
precisely aligned to this objective.

If there is some need or requirement to use the RFC3779 extensions in  
contexts other than assertions about right of use of resources by  
virtue of an allocation action, that make use of other extensions than  
are specified here, then I would suggest that it would be more  
appropriate to define a distinct profile to fulfil this function.

i.e. this is a "particular purpose" profile rather than a general  
purpose profile, and the constraint is consistent with that level of  
specificity of purpose.

>
>
> 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.

section 3.3 says "This profile specifies a minimum of SHA-256" which I  
thought would forbid the use of SHA-1

It also says that "Accordingly, the value for this field MUST be one  
of the OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 }  
[RFC4055]." which I believe that forbids the use of SHA-1 AND  
SHA-1024, or at least thats what I understand from this text.

Section 4.5 states much the same.

So it seems to me that sections 3.3 and 4.5 say the same thing.

Which means that I'm confused by your comment - when you say "For  
consistency.." my question back to you is "Consistency with _what_?" I  
would appreciate some further clarification on your comment here please.

>  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.
>

Section 3.8 refers to the subject public key, and section 3.3 refers  
to the signature algorithm used to compute the signature on the  
certificate. Aren't these  referring to different things? Again, I  
would appreciate some further clarification on your comment here please.

> 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.

I just read rfc5280 again (well, section 5 at any rate), and I  
personally cannot see a justification for your assertion that an  
issuingDistributionPoint MUST be used if the scope of a CRL is limited  
as stated in section 3.9.5. My reading of rfc5280 suggests that it is  
possible to have a restricted scope, and still not have an  
issuingDistributionPoint extension in the CRL.

As you are a co-author of 5280 it could well be that my reading of  
rfc5280 is incorrect.

Perhaps if I put it as a question:

    IF a CA wishes to limit the scope of a CRL MUST the CRL use the  
IssuingDistributionPoint extension EVERY time in EVERY CRL?

How would section 5.3.1 of rfc5280 then apply given that the reason is  
essentially "unspecified" and  5.3.1 states: "the reason code CRL  
entry extension SHOULD be absent instead of using the unspecified (0)  
reasonCode value."

The other option is to place no scope restriction on CRLs, which leads  
to the potential for a CRL signed by CA's Key B to revoke a  
certificate issued by CA's Key A. Does this "no scope" present a  
problem at all?

>
> 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.

You are suggesting s/SHOULD/MUST/ here - is that right? This change  
looks sensible to me as it should reflect a past event not a future  
intention.

So I agree with this suggested change to the text.

>
>
> 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.
>

I cannot see this uniqueness requirement mentioned anywhere in RFC5280  
- if this is a requirement then why is this requirement omitted from  
rfc5280? In the RPKI a single entity may hold resources from multiple  
sources, and therefore it is conceivable that the same subject has  
resource certificates issued by multiple CAs. in this case we were  
desirous not to force different subject names onto the same entity  
when the RPKI makes no use of distinct subject names in any case. For  
that reason uniqueness of the subject name was qualified as you quote  
- unique per issuer only.

> 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?
>

It is not acceptable, nor is it intended in the text that this was a  
possible outcome.

are you suggesting that there should be a s/MAY/MUST/ ?

i.e.:

      The CA MUST  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 this is your comment, then I agree with this.

> 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?

When there are to be no published outcomes that are signed by this EE  
certificate. For example, when the EE certificate is used to digitally  
sign a single object that is not to be published in any repository.

>
> 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?

step 2 says that the wall clock should be within the validity times of  
the certificate - this does not appear to represent any change from  
the conventional interpretation of the validity times of the  
certificate.

step3 says that valid PKI certs should conform to this profile. Again  
this does not appear to be unusual.

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

agreed

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

agreed

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

agreed

again, thanks indeed for these comments

regards,

   Geoff - who is NOT posting as wg chair in this response.

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

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 05 Sep 2008 15:26:31 -0400

> purpose profile, and the constraint is consistent with that level of 

I understand your concern.  The scenario that I was thinking about was 
one in which a CA product added non-critical extensions to a certificate 
that would not tend to affect a relying party's decision to accept the 
certificate regardless of whether the relying party could process the 
extension.  For example, below are two non-critical extensions that I 
extracted from two different certificates:

SEQUENCE {
  OBJECT IDENTIFIER
    szOID_ENROLL_CERTTYPE_EXTENSION (1 3 6 1 4 1 311 20 2)
  OCTET STRING, encapsulates {
    BMPString ''
    }
  }

SEQUENCE {
  OBJECT IDENTIFIER entrustVersInfo (1 2 840 113533 7 65 0)
  OCTET STRING, encapsulates {
    SEQUENCE {
      GeneralString 'V7.1'
      BIT STRING
        '10000001'B
      }
    }
  }

This extension was found in a CRL:

SEQUENCE {
  OBJECT IDENTIFIER
    szOID_CERTSRV_CA_VERSION (1 3 6 1 4 1 311 21 1)
  OCTET STRING, encapsulates {
    INTEGER 65537
    }
  }

It may be possible to configure these CA products so that they do not 
include these extensions in the certificates, but that is a question 
that would need to be answered by someone more familiar with the 
particular CA products used to generate the certificates.

> would appreciate some further clarification on your comment here please.

I was referring to consistency between the set of allowable hash 
algorithms and the allowable RSA key sizes (by "1024 bit keys", I meant 
RSA keys, not SHA-1024 [which does not exist]). SHA-1 provides about the 
same level of security as a 1024-bit RSA key.  So, while it is 
acceptable to create signatures using SHA-256 and a 1024 bit RSA key, 
the use of SHA-256 rather than SHA-1 doesn't really make the signature 
stronger since the 1024 bit RSA would be the weakest link.

So, for consistency, if SHA-1 is considered unacceptable then 1024 bit 
RSA keys should also be considered unacceptable.  Given the general push 
to move away from 1024 bit RSA keys, I would recommend changing section 
3.8 to make the minimum key size 2048 bits.

> would appreciate some further clarification on your comment here please.

The second paragraph in section 3.3 simply lacks context since there is 
no other mention of key sizes in that section.  The text makes much more 
sense in section 3.8 since that section specifies minimum and 
recommended key sizes.  Since the needed to verify the signature on a 
certificate must appear in the subject public key info field of the 
preceding certificate in the path, any recommendation about key sizes in 
section 3.8 implicitly covers the sizes of keys used to sign certificates.

>>  unless the CRL includes an issuingDistributionPoint extension.  So, if
>>  the scope of CRLs is to be limited to certificates signed with a given
>>  change names whenever changing the key pair used to sign certificates.
>

Yes.  Section 5 of RFC 5280 says:

   A full and complete CRL lists all unexpired
   certificates issued by a CA that have been revoked for any reason.
   (Note that since CAs and CRL issuers are identified by name, the
   scope of a CRL is not affected by the key used to sign the CRL or the
   key(s) used to sign certificates.)

Section 5.2.5 of RFC 5280 says that "[t]he issuing distribution point is 
a critical CRL extension that identifies the CRL distribution point and 
scope for a particular CRL".  The only extensions defined in RFC 5280 
for indicating that a CRL is not a full and complete CRL are the 
issuingDistributionPoint extension and the deltaCRLIndicator extension.

This can also be seen in section 6.3.3 step (b), which indicates how to 
verify that a certificate is included within the scope of a CRL.  There 
are only two steps.  Step (1) verifies that the issuer name in the CRL 
is correct. Step (2) only applies if the CRL includes an 
issuingDistributionPoint extension.

> entry extension SHOULD be absent instead of using the unspecified (0) 

How does section 5.3.1 apply to what?  Unless you are doing something 
unusual like specifying that certificates that are revoked for different 
reasons need to appear on different CRLs, the reasonCode extension has 
no effect on the set of certificates listed on a CRL.

> certificate issued by CA's Key A. Does this "no scope" present a 

I'm not sure what you mean by "place no scope restriction on CRLs".  If 
you are going to forbid the use of the issuingDistributionPoint 
extension (which may be wise since you may wish to support clients that 
cannot process this extension), then every CRL issued must be a full and 
complete CRL.  You may also want to support clients that can only use a 
CRL to determine the status of a certificate if the certificate and the 
CRL were signed using the same key.  There are two options for doing 
this while still remaining X.509 compliant: (1) have the CA create 
multiple CRLs, one for each of its keys, that all contain the same list 
of revoked certificates or (2) restrict each CA to a single key by never 
having the CA perform key rollover.  Option (2) is actually quite 
common.  Every few years when it is time to create a new key pair, a new 
"logical" CA is created with a different name from the previous CA:

    cn=Issuing CA 1, dc=example, dc=com
    cn=Issuing CA 2, dc=example, dc=com
    cn=Issuing CA 3, dc=example, dc=com
    ...

> So I agree with this suggested change to the text.

Yes, that is what I am suggesting.

>> 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

In RFC 5280, you will really only find this explicitly stated in the 
Security Considerations section in the paragraph that begins with the 
following sentence:

   While X.509 mandates that names be unambiguous, there is a risk that
   two unrelated authorities will issue certificates and/or CRLs under
   the same issuer name.

You can find a lot more if you sift through the relevant X.500 
documents.  The name form used in the issuer and subject fields of 
certificates is defined in X.501, which states the following:

   A (directory) name is a construct that identifies a particular object 
from
   among the set of all objects. A name shall be unambiguous, that is,
   denotes just one object. However, a name need not be unique, that is, be
   the only name that unambiguously denotes the object.

   An object can be assigned a distinguished name without being represented
   by an entry in the Directory, but this name is then the name its 
object entry
   would have had were it represented in the Directory.

   Syntactically, each name for an object or entry is an ordered sequence of
   relative distinguished names.

The following text also appears in X.509:

   For every name form used in the GeneralName type, there shall be a name
   registration system that ensures that any name used unambiguously 
identifies
   one entity to both certificate issuer and certificate users.

This text specifically appears with respect to the subjectAltName 
extension, but since directoryName is one of the name forms that appears 
in the GeneralName type, it also applies to the issuer and subject fields.

The problem with a less stringent requirement is that if two CAs issue 
certificates and CRLs under the same name, there is a risk that a 
relying party will use a CRL issued by one of these CAs to determine the 
status of a certificate issued by the other CA (see note above about RFC 
5280 section 6.3.3 step (b)).

>
>> 6) The following two paragraphs in Section 5.3 (under BasicConstraints)
>> seem inconsistent:
>>
>>       certificate with the BasicConstraints extension not present in the
>>       issued certificate.
>>

Yes, this change would make the two paragraphs that I quoted more 
consistent.

>> that the certificate request for an EE certificate MUST include the SIA
>> Under what circumstances (if any) is it not a requirement to include an

OK. I would suggest modifying the final paragraph under 
SubjectInformationAccess in Section 5.3 to make it clear that the 
requirement does not appear whenever the "EE certificate is used to sign 
a single object", but only when the signed object will appear in the 
repository (i.e., that certificates may sometimes be used to sign 
objects what will not appear in the repository).

> the conventional interpretation of the validity times of the certificate.
>

I guess I meant steps 3 and 4:

   3.  The certificate contains all fields that MUST be present and
       contains field values as specified in this profile for all field
       values that MUST be present.

   4.  No field value that MUST NOT be present in this profile is
       present in the certificate.

As an example of the problem with these requirements, consider the 
basicConstraints extension.  An off-the-self path validation library 
will verify that every intermediate certificate includes a 
basicConstraints extension with cA=TRUE, since this is an X.509 
requirement.  The library will not verify that the basicConstraints 
extensions are marked critical nor will they verify that the end entity 
certificate does not include a basicConstraints extension, since these 
things do not affect the validity of the path.  Step 3 requires 
customizing the software to verify that the basicConstraints extension 
in every intermediate certificate is marked critical and step 4 requires 
customizing the software to verify that the basicConstraints extension 
is omitted from the end entity certificate.

Note that while RFC 5280 imposes constraints on the issuance of 
certificates beyond those imposed by X.509, the third paragraph of 
section 6.1 specifically recommends against adding additional checks to 
the path validation algorithm for the sole purpose of verifying that the 
certificates were issued in conformance with RFC 5280.

Dave

---

From: Geoff Huston <[email-masked]>
Date: Sat, 6 Sep 2008 16:23:06 +1000

On 06/09/2008, at 5:26 AM, David A. Cooper wrote:

>> We (the authors of this draft) did not want to be in the position  
>> of having certificates with extensions which relying parties may  
>> see as valid, but contain extensions that, were the replying party  
>> to understand the extension, would contradict or qualify in some  
>> wthis original validity.
>>
>> the approach of nomination of a specific goal for the PKI, namely  
>> to construct a PKI that precisely matches the IP number resource  
>> allocation structure, and then defining a certificate profile that  
>> was precisely aligned to this objective.
>>
>> If there is some need or requirement to use the RFC3779 extensions  
>> in contexts other than assertions about right of use of resources  
>> by virtue of an allocation action, that make use of other  
>> extensions than are specified here, then I would suggest that it  
>> would be more appropriate to define a distinct profile to fulfil  
>> this function.
>>
>> purpose profile, and the constraint is consistent with that level  
>> of specificity of purpose.
>
> I understand your concern.  The scenario that I was thinking about  
> was one in which a CA product added non-critical extensions to a  
> certificate that would not tend to affect a relying party's decision  
> to accept the certificate regardless of whether the relying party  
> could process the extension.  For example, below are two non- 
> critical extensions that I extracted from two different certificates:
>
> SEQUENCE {
> OBJECT IDENTIFIER
> It may be possible to configure these CA products so that they do  
> not include these extensions in the certificates, but that is a  
> question that would need to be answered by someone more familiar  
> with the particular CA products used to generate the certificates.

I'll document this as an unresolved issue at the moment, and I'd  
appreciate any further comments on this matter from other WG members.

>> section 3.3 says "This profile specifies a minimum of SHA-256"  
>> which I thought would forbid the use of SHA-1
>>
>> It also says that "Accordingly, the value for this field MUST be  
>> one of the OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 }  
>> consistency.." my question back to you is "Consistency with  
>> _what_?" I would appreciate some further clarification on your  
>> comment here please.
>
> algorithms and the allowable RSA key sizes (by "1024 bit keys", I  
> meant RSA keys, not SHA-1024 [which does not exist]). SHA-1 provides  
> about the same level of security as a 1024-bit RSA key.  So, while  
> it is acceptable to create signatures using SHA-256 and a 1024 bit  
> RSA key, the use of SHA-256 rather than SHA-1 doesn't really make  
> the signature stronger since the 1024 bit RSA would be the weakest  
> link.
>
> So, for consistency, if SHA-1 is considered unacceptable then 1024  
> bit RSA keys should also be considered unacceptable.  Given the  
> general push to move away from 1024 bit RSA keys, I would recommend  
> changing section 3.8 to make the minimum key size 2048 bits.
>

thank you for this clarification - I'll make the change to 3.8 to  
specify a minimum key size of 2048 bits.

>> Section 3.8 refers to the subject public key, and section 3.3  
>> refers to the signature algorithm used to compute the signature on  
>> the certificate. Aren't these  referring to different things?  
>> Again, I would appreciate some further clarification on your  
>> comment here please.
>>
>
> The second paragraph in section 3.3 simply lacks context since there  
> is no other mention of key sizes in that section.  The text makes  
> much more sense in section 3.8 since that section specifies minimum  
> and recommended key sizes.  Since the needed to verify the signature  
> on a certificate must appear in the subject public key info field of  
> the preceding certificate in the path, any recommendation about key  
> sizes in section 3.8 implicitly covers the sizes of keys used to  
> sign certificates.

Again thanks for the clarification - I'll strike out the second  
paragraph of section 3.3

>> issuingDistributionPoint MUST be used if the scope of a CRL is  
>> limited as stated in section 3.9.5. My reading of rfc5280 suggests  
>> that it is possible to have a restricted scope, and still not have  
>> an issuingDistributionPoint extension in the CRL.
>>
> Section 5.2.5 of RFC 5280 says that "[t]he issuing distribution  
> point is a critical CRL extension that identifies the CRL  
> distribution point and scope for a particular CRL".  The only  
> extensions defined in RFC 5280 for indicating that a CRL is not a  
> full and complete CRL are the issuingDistributionPoint extension and  
> the deltaCRLIndicator extension.
>
> This can also be seen in section 6.3.3 step (b), which indicates how  
> to verify that a certificate is included within the scope of a CRL.   
> There are only two steps.  Step (1) verifies that the issuer name in  
> the CRL is correct. Step (2) only applies if the CRL includes an  
>> How would section 5.3.1 of rfc5280 then apply given that the reason  
>> is essentially "unspecified" and  5.3.1 states: "the reason code  
>> CRL entry extension SHOULD be absent instead of using the  
>> unspecified (0) reasonCode value."
>
> How does section 5.3.1 apply to what?  Unless you are doing  
> something unusual like specifying that certificates that are revoked  
> for different reasons need to appear on different CRLs, the  
> reasonCode extension has no effect on the set of certificates listed  
> on a CRL.
>
>> The other option is to place no scope restriction on CRLs, which  
>> leads to the potential for a CRL signed by CA's Key B to revoke a  
> I'm not sure what you mean by "place no scope restriction on CRLs".   
> If you are going to forbid the use of the issuingDistributionPoint  
> extension (which may be wise since you may wish to support clients  
> that cannot process this extension), then every CRL issued must be a  
> full and complete CRL.  You may also want to support clients that  
> can only use a CRL to determine the status of a certificate if the  
> certificate and the CRL were signed using the same key.  There are  
> two options for doing this while still remaining X.509 compliant:  
> (1) have the CA create multiple CRLs, one for each of its keys, that  
> all contain the same list of revoked certificates or (2) restrict  
> each CA to a single key by never having the CA perform key  
> rollover.  Option (2) is actually quite common.  Every few years  
> when it is time to create a new key pair, a new "logical" CA is  
> created with a different name from the previous CA:
>

I'll document this as an unresolved issue at the moment, and I'd  
appreciate any further comments on this matter from other WG members.

I think it may be the easiest course of action to drop the scope  
restriction, but further comment may be helpful to understand if this  
would present any other issues in the scope of the RPKI.

> Yes, that is what I am suggesting.

agreed.

>> I cannot see this uniqueness requirement mentioned anywhere in  
>> RFC5280 - if this is a requirement then why is this requirement  
>> omitted from rfc5280? In the RPKI a single entity may hold  
>> resources from multiple sources, and therefore it is conceivable  
>> that the same subject has resource certificates issued by multiple  
>> CAs. in this case we were desirous not to force different subject  
>> names onto the same entity when the RPKI makes no use of distinct  
>> subject names in any case. For that reason uniqueness of the  
>> subject name was qualified as you quote - unique per issuer only.
>
> Security Considerations section in the paragraph that begins with  
> the following sentence:
>
> A (directory) name is a construct that identifies a particular  
> object from
> extension, but since directoryName is one of the name forms that  
> appears in the GeneralName type, it also applies to the issuer and  
> subject fields.
>
> The problem with a less stringent requirement is that if two CAs  
> issue certificates and CRLs under the same name, there is a risk  
> that a relying party will use a CRL issued by one of these CAs to  
> determine the status of a certificate issued by the other CA (see  
> note above about RFC 5280 section 6.3.3 step (b)).
>

Becuase:

- the RPKI is strictly hierarchical

- the repository publication structure is structured on a per-CA basis

- the CRLDP is mandatory to include in all RPKI certificates (except  
apex self-signed certs) so that each certificate points directly to  
the associated CRL that can revoke it

- the requirement in X.509 and RFC5280 requires that names be  
unambiguous rather than unique as far as I can tell

- a single entity may hold resources from multiple sources and the  
name space is neither coordinated nor restricted to be structured in  
any fashion

- the RPKI is not attesting a name or an identity but a right to use  
resources

then I suggest that because the context of names is one that positions  
names within a strict hierarchy, then unambiguity is achieved when  
names are specified to be unique per issuer.

So I propose not to change the text on that basis.

>> It is not acceptable, nor is it intended in the text that this was  
>> a possible outcome.
>>

agreed.

>> When there are to be no published outcomes that are signed by this  
>> EE certificate. For example, when the EE certificate is used to  
>> digitally sign a single object that is not to be published in any  
>> repository.
>
> requirement does not appear whenever the "EE certificate is used to  
> sign a single object", but only when the signed object will appear  
> in the repository (i.e., that certificates may sometimes be used to  
> sign objects what will not appear in the repository).
>

agreed.

>> step 2 says that the wall clock should be within the validity times  
>> of the certificate - this does not appear to represent any change  
>> from the conventional interpretation of the validity times of the  
>> certificate.
>>
>> step3 says that valid PKI certs should conform to this profile.  
>> Again this does not appear to be unusual.
>
> extensions are marked critical nor will they verify that the end  
> entity certificate does not include a basicConstraints extension,  
> since these things do not affect the validity of the path.  Step 3  
> requires customizing the software to verify that the  
> basicConstraints extension in every intermediate certificate is  
> marked critical and step 4 requires customizing the software to  
> verify that the basicConstraints extension is omitted from the end  
> entity certificate.
>
> section 6.1 specifically recommends against adding additional checks  
> to the path validation algorithm for the sole purpose of verifying  
> that the certificates were issued in conformance with RFC 5280.
>

Yes, because of the mandatory validation of the resource extension in  
RPKI certificates in certification paths, any "off the shelf path  
validation software that does not strictly apply the RPKI validation  
checks is entirely inappropriate to use, and the requirements of steps  
3 and 4 very definitely are intended to be applied.

regards,

   Geoff