On Feb 24, 2014, at 11:41, Stephen Kent <[email protected]> wrote:
> Rob,
>
> Good catch.
>> Obscure little conflict that only an implementor would notice: there's
>> a three-way conflict between the current rtr-keying draft, the current
>> bgpsec-pki-profile draft, and the base RPKI certificate profile RFC.
>>
>> The problem is with router-ids and the subject field in the PKCS #10
>> request.
>>
>> - draft-ietf-sidr-bgpsec-pki-profiles-06 3.1.1.1 (talking about
>> certificates, not certificate requests) says router certificate
>> names SHOULD be /commonName=ROUTER-aaaaaaaa/serialNumber=rrrrrrrr,
>> where aaaaaaaa is the ASN and rrrrrrrr is the router-id, as 32-bits
>> hex in both cases. OK, fine.
>>
>> As far as I can tell, this is the only way in which the router-id is
>> encoded anywhere in the certificate.
> yep.
>> - draft-ietf-sidr-bgpsec-pki-profiles-06 3.2 says that the certificate
>> request profile matches RFC 6487 with a few specific differences,
>> none of which have anything to do with subject names.
> yep.
>> - draft-ietf-sidr-rtr-keying-04 3.1 says that when a router is
>> generating keys, it includes the router-id in the PKCS #10.
> this seems to be the place where there is an error, given you observation re
> 6487, 6.1.1.
>> Given that the only place we have to encode the router-id is in the
>> subject name (as opposed to, say, a newly-defined X.509v3
>> extension), this text would seem to imply that the PKCS #10 includes
>> a non-empty Subject field.
>> - RFC 6487 6.1.1 says that the Subject field of the PKCS #10 MUST be
>> absent or empty except when requesting reissuance of an existing key
>> and even then only if the CA's CPS allows reusing subject names.
>>
>> I see no way to reconcile all of this without changing something.
> a router cert is issued by an ISP to one if its routers. it's not clear to
> me that a PKCS #10 request is strictly required for this, as it is a local
> process
> within an AS. But, if one does use PKCS #10 then a CA operating within an
> AS context can probably determine the ID of the router making the request.
> I suggest this mismatch ought to be addressed in the rtr keying I-D.
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. 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.
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?
spt
[1] http://datatracker.ietf.org/doc/rfc2986/
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
