Re: draft-ietf-sidr-res-certs-06.txt

[Rob Austein <sra@hactrn.net>]

At Tue, 24 Apr 2007 11:43:18 +1000, Geoff Huston wrote:
> 
> I think the text you are referring to is:
> 
> "Alternatively, if the certificate issuer does not maintain a persistent 
> URL for the must recent issued certificate for each subject, then the 
> entity who is subject of a certificate MAY keep the most recent copy of 
> the superior's issued certificate in the subject's publication space, 
> and set the AIA to reference this subject-maintained copy of the 
> immediate superior certificate. "
> ...
> Now all seems somewhat strange to me as well, and the other option is to 
> just drop this paragraph from the text and just leave the text in the 
> previous paragraph of "CA Certificate Issuers SHOULD use a  persistent 
> URL name scheme for issued certificates" as being sufficient.
> 
> Does this make more sense? (dropping the offering paragraph altogether)

I think dropping it makes sense.

> I had originally discovered RFC4211 (CRMF) and drafted the earlier 
> versions of this document in terms of CRMF as I thought that this was a 
> standards compliant approach. Thenm I found out that OpenSSL used 
> PKCS#10, so I put in a section as to what made sense in terms of PKCS#10 
> (and what made sense in terms of OpenSSL use)
> 
> I agree completely with your comments, but I have no clear idea of the 
> relative prospects for CRMF and PKCS#10 in terms of available 
> implementations and general use, so I have no idea what would be the 
> better choice if one has to just pick one or the other for this profile.
> 
> Do you have any suggestion as to what to do here?

Unless someone has a better theory: Make PKCS#10 mandatory and CRMF
optional for now, update spec if and when CRMF takes over the world.

> > - The RFC 3779 extensions used to be set by the issuer and were not
> >   allowed in requests.  This has changed to allow the subject to
> >   request a certificate that covers only a subset of the total set of
> >   resources.  This appears to duplicate functionality in the up-down
> >   protocol; I haven't yet figured out whether there's a good reason
> >   for this duplication.
>
> Yep, I have a similar degree of uncertainty here. One option is to 
> remove this from the defined set of extensions in the request, deferring 
> the nomination of an explicitly specified resource set to be something 
> that needs to be  specified outside of the certificate request (which we 
> can do in the associated subject / issuer "up/down" protocol in our model).
> 
> Would you be happier to see this extension in the request dropped?

As RobK suggests, we probably only want it in one place, whether that
be here or in the up-down protocol.   I can go either way on which one
we drop.

> > - There's some new text stating that the issuer is not allowed to muck
> >   with the subject's SIA extension.  This seems reasonable at first
> >   glance, but the issuer is allowed to muck with -everything- else
> >   except for the subject's public key; in this context, excepting just
> >   the SIA seems strange and suggests that I'm not understanding the
> >   motivation behind this change.
> 
> I thought that this reflected a position that a subject of a CA 
> certificate has the freedom in this profile to select their publication 
> point for information and services relating to "products" of this 
> certificate and should not have this choice of publication point 
> restrained by the CA certificate issuer. Thats the motivation for the 
> change. The Issuer and subject can still reach an agreement as to what 
> this SIA value should be, but the wording in the draft implies that this 
> would need to be something that is negotiated prior to the generation of 
> the certificate request.
> 
> Is this additional description of the motivation enough, or do you 
> believe that the draft needs some additional / changed words here?

It's more a question: are there really no other fields that are
controlled by the subject rather than the issuer?  Maybe it's just the
phrasing that threw me: the (perhaps unintentional) implication that
everything -except- the SIA extension and the subject's public key is
controlled by the issuer.

> > - With no offense intended, I was not able to understand or even parse
> >   the Security Considerations section.  If I were reviewing this
> >   document for the security directorate, I would have to bounce it on
> >   these grounds, as I am required to assume that if I can't make any
> >   sense of this section, other readers might also be confused.
> 
> I was attempting to convey the basic message that as a specific profile 
> of RFC3280 using the extensions in RFC 3779, there was no novel or 
> otherwise changed security aspects of this profile (para 1)

That part's ok (I'd drop "and their use" but that's a nit).

> Secondly I was attempting to state that certificates are no better in 
> terms of describing the resource allocation state as the underlying 
> resource allocation databases upon which resource certificate issuance 
> is based (para 2).
> 
> Do you have any suggestions here for alternative wording that can make 
> this message clearer?

"A Resource Certificate PKI is only as good as the underlying database
from which it is generated.  If the underlying database contains
ambiguities, overlaps, or other errors, so will the PKI."

Or something like that.  Tweak to taste, but I strongly recommend
short sentences and small words.

> > - I still think we need some kind of signed manifest, which would
> >   probably have to go in this document.
>
> I'm not sure that I would agree that it would need to go in this 
> document. This document does not encompass specification of 
> repositories, object nameing schemes within such repositories, and 
> potential operations by relying parties such as object aggregation and 
> local caching that would both provide adequate context and motivate the 
> need to specify a manifest. It strikes me as logical that all this 
> material sits in a different document. In such a case its not entirely 
> clear tyo me whether this second document is necessarily an IETF 
> Standards Track document, and, if so, which IETF WG would have the 
> carriage of it.

It seems logical to me that it be part of this document because it'd
be part of the repository data and because the problem it attempts to
solve is implicit in the use of URIs as specified in this document.