| | | | | | | | |
|
|
|
You're here: Home |
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)
(A voice from the crowd: yes!)
My reading of RFC3280 (section 4.2.1.5) is that this refers to the Issuer as distinct to referring to the subject (The text I read that lead to this conclusion was "the CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA.")- The certificate policy extension is now set by the issuer; this is a change, it used to be set by the subject. I haven't yet figured out whether this is a good change.
The policy as such is always assigned by the issuer, since the issuer's CA works by "implementing" that policy. Therefore it doesn't really matter what the subject wants here.
Geoff be careful, you're quoting text that refers to the CPS, not the CP.
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).- 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.Would you be happier to see this extension in the request dropped?
I'd strongly advocate to have it in only one place: either in the request or in the protocol, otherwise we could have contradicting inputs.
(A related note: maybe not everybody will use the up-down protocol to apply for certificates. For those who DO use the up-down protocol, it's almost indifferent where you put the set of resources asked-for. If we say that this information is contained in the request, then those who do not use the up-down protocol will have a well-defined way to exchange this information.)
- 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?
(I fully agree with RobL's note here: unless it's an degenerated case, the CA has no say on what the SIA value should be.)
I can see some ambiguity in the use of the terms "CA" and "Certificate Authorities". I can clean this up to limit the use of the term "CA" to refer to an entity that issues certificates.- Terminology in this draft is a bit messy, in particular the string "CA" sometimes means a CA, sometimes an issuer, and sometimes a certificate. I also expect somebody to object to the phrase "self-signed certificate", so it'd be simplest to clean that up before kicking the draft to the IESG.I did a cut and paste of the "self-signed certificate" from RFC3280, and had assumed that if the use of the term was good enough in RFC 3280 it was good enough in the context of resource certs (!).
"Self-signed" is in fact the official term. Robert
