At Fri, 4 Apr 2014 11:41:06 -0400, Sean P Turner wrote:
>
> Finally getting back around to this.
>
> Two points I think need to be made:
>
> 1. Can you omit the subject name from a PKCS#10?
>
> I don t think so. The syntax for PKCS#10 is [1]:
>
> CertificationRequestInfo ::= SEQUENCE {
> version INTEGER { v1(0) } (v1,...),
> subject Name,
> subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
> attributes [0] Attributes{{ CRIAttributes }}
> }
>
> Note there s no OPTIONAL after Name. It could be pretty easily
> argued that completely omitting the field would result in a
> non-interoperable certificate request; that is a certificate request
> that CAs might choke on because at a minimum they re expecting a
> NULL subject name.
I agree.
One might reasonably wonder why none of the existing implementations
are choking on this. The answer appears to be that we are all quietly
violating RFC 6487 on this point and nobody noticed. Oops.
- My up-down client (which is, I think, the only client against which
all of the up-down servers have been tested) includes a subject name
in the PKCS #10 request, more by accident than by intent -- since,
until router certificates came along, subject names in RPKI
certificates were meaningless by design, the internal API constructs
appropriate meaningless subject names as needed when the caller
doesn't supply them, and I forgot to disable this for the specific
case of PKCS #10 requests in the up-down protocol.
- The fact that this has never caused an interoperability problem
strongly suggests that none of the servers are checking for this
(meaningless) subject name in the PKCS #10. I've confirmed that
mine doesn't check: I do check all the required and forbidden
extensions and so forth, but completely ignore the incoming PKCS #10
subject name (ie, neither check it nor use it for anything later).
I haven't done a code dive on any of the other implementations, but
behavior on the wire to date suggests that we all ignore the subject
name that RFC 6487 says should not be there.
So, again: oops. But this does tend to support your analysis.
> Based on this I think the text in RFC 6487 might need to be tweaked
> based on not being able to omit subject from PKCS#10:
>
> OLD:
>
> Subject
> This field MAY be omitted. If present, the value of this field
> SHOULD be empty (i.e., NULL), in which case the CA MUST
> generate a subject name that is unique in the context of
> certificates issued by this CA.
>
> NEW:
>
> Subject
> This field is mandatory and MUST be included; however,
> the value of this field
> SHOULD be empty (i.e., NULL), in which case the CA MUST
> generate a subject name that is unique in the context of
> certificates issued by this CA.
This seems reasonable, and, given the current apparent behavior, seems
unlikely to cause any problems.
> 2. Is rtr-keying correct in stating the following in s3.1 because
> the text there is about initial provisioning not rekey/renewal and
> it contradicts the 2nd sentence about subject in RFC 6847?
>
> s3.1 rtr-keying:
>
> to generate the PKCS#10 request that includes the router number and
> public key ...
>
> s6.1 RFC 6487:
>
> This field is allowed to be
> non-empty only for a re-key/reissuance request, and only if the
> CA has adopted a policy (in its Certificate Practice Statement
> (CPS)) that permits reuse of names in these circumstances.
>
> I m wondering how the router is going to know what value to use. I
> suspect its only going to know what value to use after it has been
> told the value :) Not including a router # in the request is
> probably okay if the request comes through the CLI session the
> operator is using to talk to the router because it can capture the
> request and "tag it" in someway to know what name ought to go in the
> subject field of the issued certificate. But, say the CLI session
> isn t used and the router uses its network connectivity to
> communicate with the CA. If there s no name in the request, how
> will the CA know what name to include in the issued certificate?
> Seems to me like for that scenario, we d actually want the subject
> name present in the PKCS#10. Thoughts?
The authors of RFC 6487 can speak for themselves, but I think their
intent was to avoid requests for "vanity names" (CN="Joe's Pizza"
instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which could
be construed as eroding claims that the RPKI attests only to things
like addresses and autonomous system numbers.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
