Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments

From: Geoff Huston <[email-masked]>
Date: Wed, 04 Apr 2007 14:59:01 +1000

At 08:38 PM 26/03/2007, Robert Kisteleki wrote:
>Hello,
>
>Please find my comments below for discussion.

Thank you indeed for this review. I've responded to each of your 
comments in turn. I have raised some followup questions in some of 
these response, and I'd appreciate your views on these questions!

Geoff

>1. Typo at the bottom of page 6: RSA-SHA-384 OID is {pkcs-1 12}, not 
>{pkcs-1 11}

agreed

>2. In 3.9.5: Just as with the AIA, CRLDP should not appear in a root 
>certificate.

I looked for this in RFC3280 and could not find such a constraint for 
CRLDP, but could find it for the AIA.

I propose adding the text to the CRLDP section (3.9.5)

This extension MUST be present and it is non-critical. [new text ->] 
There is one exception; where a CA distributes its public key in the 
form of a "self-signed" certificate, the CRLDP MUST be omitted.

I also propose adding the following para to the AIA section (3.9.6)

As noted in Section 4.2.1.1 of RFC3280, there is one exception; where 
a CA distributes its public key in the form of a "self-signed" 
certificate, the authority key identifier MAY be omitted.

>3.In 4, last paragraph: "... Where two or more CRLs issued by a 
>single CA are present in a certificate repository, the CRL with the 
>highest value of the "CRL Number" field supersedes all other CRLs 
>issued by this CA."
>
>When doing a rekey, a CA may have more than one key pair working in 
>parallel, therefore must issue more than one CRL. In this case, the 
>highest CRL number does not supersede all CRLs by that CA.

I've consulted section 5.2.3 of RFC 3280 and the text is that a CRL 
Number "conveys a monotonically increasing sequence number for a 
given CRL scope and CRL issuer. This extension allows users to easily 
determine when a particular CRL supersedes another CRL."

Section 4 of this draft already defines the scope as "all 
certificates issued by this CA" and the "The CRL Issuer is the CA"

So even when re-keying in the CA, RFC3280 appears to indicate that 
the highest CRL supersedes all other CRL.

I don't propose changing the text at this point, as it appears that 
the draft's text is already consistent with RFC 3280.

(I must admit that I'm a bit at sea when thinking about a certificate 
issued with CA's key pair A being revoked with CA's key pair B, but 
my interpretation of the text in 3280 appear to allow precisely that!)

>4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, I 
>miss RSA-SHA-384 and RSA-SHA-512 from here.

There is no a priori requirement that the same algorithms options be 
present for CRLs. and yes, the profile says only SHA-256. Do you see 
merit in adding RSA-SHA-384 and RSA-SHA-512 for CRLs?

>5. In 5, I miss an introductory paragraph stating something like "a 
>resource certificate request can be either PKCS#10 or CRMF". Without 
>it, it is quite unclear why two different request formats are described below.

ok - I'll add

"A resource certificate request MAY use either of PKCS#10 or 
Certificate Request Message Format (CRMF). There is no requirement 
for a CA Issuer to support both request formats, and the choice of 
formats is a matter for the Issuer and Subject to resolve."

Is this suitable?

>6. In 5.1.1, signatureAlgorithm: again RSA-SHA-384 and RSA-SHA-512 
>options are missing.

noted - new text added as per 3.3

>7. In 5.2.2, Resource Class: As the subject can also use PKCS#10 
>which does not have this option, I don't really see why is this 
>field is a MUST. Also, when generating a request, the subject may 
>not be aware of exactly which resource class that request/keypair 
>will be used with, in which case this field cannot be filled in.

Yes, it appears that the subject and issuer have to figure out which 
CA is the target of the request through mechanisms other than control 
fields in the request itself. I'll remove the test.

Should Authenticator Control be removed as well?

>8. Section 5.3 starts with "This profile allows the following 
>extensions to appear..." and then goes on describing fields which 
>"MUST be omitted". I find this a bit confusing.

rewording :

"The following extensions may appear in a PKCS#10 or CRMF Certificate 
Request. This profile places the following additional constraints on 
these extensions."

>9. Section 5.3 lists the "SubjectInformationAccess" field twice, 
>with slightly different text. I believe the second appearance should 
>be simply omitted.

agreed

>10. Same duplicate with SubjectAlternateName (also in 5.3).

agreed

>11. At the very end of 5.3: I think the CA should not alter the 
>SubjectInformationAccess requested by the subject. There is a reason 
>why the subject asked for any particular URL: that is the adress 
>they will be able to publish to. If the CA deliberately changes 
>this, then the subject may end up with an unusable certificate.

agreed s/MAY/MUST/

>12. In 6.1 we see "The only exception to the "no loop" condition 
>would be where a putative trust anchor may issue a self-signed root 
>certificate." This is confusing: "a self-signed certificate" by 
>definition cannot be issued by anyone else but itself. The may be 
>signed by the trust anchor key though.

Its probably better to remove this sentence, and add the following

The trust anchor information, describing a CA that serves as a trust 
anchor, includes the following:
   (1) the trusted issuer name,
   (2) the trusted public key algorithm,
   (3)the trusted public key,
   (4)optionally, the trusted public key parameters associated with 
the public key, and
   (5) a resource set, consisting of a set of IPv4 resources, IPv6 
resources and AS number resources.

The trust anchor information may be provided to the path processing 
procedure in the form of a self-signed certificate.

>13. In 6.3.: "... from the Root Trust Anchors via ..." The term 
>"Root Trust Anchor" is strange for me.
>

s/Root Trust Anchor/trust anchor CAs/ ?

>14. In the example in Appendix A, the SIA value is syntactically 
>wrong according to 3.9.7, as it does not end with '/'. Also, 
>although it is theoretically not wrong, I miss the '.cer' extension 
>from the end of the AIA value.
>

will fix!

>Cheers,
>Robert

thanks,

   Geoff

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

---

From: Robert Kisteleki <[email-masked]>
Date: Wed, 04 Apr 2007 10:01:50 +0200

Hello,

> issued with CA's key pair A being revoked with CA's key pair B, but my 
> interpretation of the text in 3280 appear to allow precisely that!)

We may have to ask for some guidance from the PKIX folk on this one.

> merit in adding RSA-SHA-384 and RSA-SHA-512 for CRLs?

It only seems logical to allow it here too.

>> 7. In 5.2.2, Resource Class: As the subject can also use PKCS#10 which 
>> does not have this option, I don't really see why is this field is a 
>> MUST. Also, when generating a request, the subject may not be aware of 
>> exactly which resource class that request/keypair will be used with, 
>> in which case this field cannot be filled in.
> 
> Yes, it appears that the subject and issuer have to figure out which CA 
> is the target of the request through mechanisms other than control 

I believe it could be useful, so we probably want allow it.

>> 12. In 6.1 we see "The only exception to the "no loop" condition would 
>> be where a putative trust anchor may issue a self-signed root 
>   (4)optionally, the trusted public key parameters associated with the 
> public key, and

I believe that regarding a TA:
- (1) is optional
- (5) is optional
- A URL for top-down chaining (practically a "starting SIA") is useful, 
therefore optional.

Cheers,
Robert

---

From: Geoff Huston <[email-masked]>
Date: Wed, 04 Apr 2007 19:04:17 +1000

>>The trust anchor information, describing a CA that serves as a 
>>trust anchor, includes the following:
>- A URL for top-down chaining (practically a "starting SIA") is 
>useful, therefore optional.

Hmm - 1 through 4 are a direct cut and past from RFC3280  - I don't 
see the logic that turns (1) into optional here given that it is part 
of the trust anchor information describing a trusted CA.

(5) is based on the implications of a resource certificate attribute 
- saying you trust a given CA is fine, but in the context of a 
resource PKI the statement is "I trust a CA with regard to being 
authoritative to certify the following resources. Accordingly, (5) 
does not appear to be optional in this context.

I note that any reference to an SIA is not present in RFC 3280  - 
given that this document defines a particular profile of that 
specification for use in a RPKI context, then why is a URL necessary 
here in this profile, but not in the more general case as described in RFC3280?

thanks,
   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Apr 2007 10:10:20 -0400

At 2:59 PM +1000 4/4/07, Geoff Huston wrote:
>...
>given CRL scope and CRL issuer. This extension allows users to 
>easily determine when a particular CRL supersedes another CRL."
>

When a CA is re-keyed, that establishes a new scope, so there will be 
two CRL sequences, one for the old key and one for the new key. I 
realized this last year when Robert and I were discussing this topic 
and I sent a message trying to clarify the conclusion we reached back 
then. Both the old and new CRLs need to be present in parallel, until 
all the old certs expire or until the old CA cert expires, whichever 
comes first. The sequences for both sets of CRLs are numbered 
independently.

>>4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, 
>>I miss RSA-SHA-384 and RSA-SHA-512 from here.
>

all of the text that talks about multiple hash algorithms has a 
problem, i.e., it does not establish what a CA and an RP MUST 
support. We need to be more explicit here.  We cannot allow a CA to 
use algorithms that we do not require ALL RPs to support.

>procedure in the form of a self-signed certificate.

I agree with this TA description, although I would delete the word 
"trusted" from the items, because its redundant.  1-4 are defined in 
3280 and 5 is defined as the additional set of parameters needed by 
3779, so this is correct.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 05 Apr 2007 11:01:56 +1000

>(I must admit that I'm a bit at sea when thinking about a 
>certificate issued with CA's key pair A being revoked with CA's key 
>pair B, but my interpretation of the text in 3280 appear to allow 
>precisely that!)

After thinking about this some more, I propose the following text

"The CRL Number extension conveys a monotonically increasing sequence 
number of positive integers for a given CA and scope. This extension 
allows users to easily determine when a particular CRL supersedes 
another CRL. The highest CRL Number value supersedes all other CRLs 
issued by the CA with the same scope."

And to define the scope of the CRL in the PKI as follows:

"The scope of the CRL MUST be "all certificates issued by this CA 
using a given key pair". The contents of the CRL are a list of all 
non-expired certificates issued by the CA using a given key pair that 
have been revoked by the CA.

[...]

The profile allows the issuance of multiple current CRLs with 
different scope by a single CA, with the scope being defined by the 
key pair used by the CA."

Is this text clearer?

   Geoff

---

From: Robert Loomans <[email-masked]>
Date: Thu, 05 Apr 2007 12:35:44 +1000

> I note that any reference to an SIA is not present in RFC 3280  - given
> that this document defines a particular profile of that specification
> for use in a RPKI context, then why is a URL necessary here in this
> profile, but not in the more general case as described in RFC3280?

I think it is in the nature of the PKI. Most other PKIs know a priori
where to find the certificate store, or they are provided with the cert
chain with a request.

"Enterprise" applications are probably just know. For S/MIME, HTTPS and
most other internet applications provide the cert chain.

I don't believe that many other PKIs have the need to retrieve all of
the published objects, starting just from TA material.

I have echoes of a conversation with Steve Kent or Russ Housley playing
in my head, but the closest I can come to a quote is that we appear to
have one of the few useful applications of SIA. So I suspect that it
just hasn't come up before.

I think that the TA material in our profile appears to be (1) through
(4) that we inherit from 3280, (5) that we get from 3779, and in this
profile we should probably add a (6) for the URL.... Which will be the
SIA, if the TA is provided as a self-signed cert.

Alternatively, if there isn't a URL in the TA material, where do we
start pulling pulling certs from?

Rob

-- 
Robert Loomans                                 Email:  [email-masked]
Programmer/Analyst, APNIC                      Phone:    +61 7 3858 3100
http://www.apnic.net                             Fax:    +61 7 3858 3199
_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Apr 2007 17:28:46 -0400

>"The CRL Number extension conveys a monotonically increasing 
>sequence number of positive integers for a given CA and scope. This 
>extension allows users to easily determine when a particular CRL 
>supersedes another CRL. The highest CRL Number value supersedes all 
>other CRLs issued by the CA with the same scope."
>

The scope of the CRL is the set of certificates issued by this CA 
under a given key. Thus the CRL contains the list of all revoked, 
non-expired certificates issued by the CA using that key.

The profile allows the issuance of multiple current CRLs with 
different scope by a single CA, with the scope being defined by the 
key used by the CA. Thus if a CA acquires a new certificate, 
containing a new public key (a re-key of the CA), the CA will begin 
issuing a separate sequence of CRLs under that new key. In contrast, 
if a CA acquire a new certificate but uses the same public key in 
that certificate (a certificate renewal) the extant CRL sequence is 
maintained.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Sat, 07 Apr 2007 11:33:36 +1000

At 07:28 AM 7/04/2007, Stephen Kent wrote:
>that certificate (a certificate renewal) the extant CRL sequence is maintained.

thanks Steve for this text - I agree with this description of the CRL 
scope (as does Rob Kisteleki I believe), and I will add this text  to 
the draft.

regards,

    Geoff