Re: [pkix] Possible new work item: additional methods for generating key identifiers

["Santosh Chokhani" <[e-mail]>]

Stefan,

CA should and the ones I know do permit you to enter a SKID.

Since there is no specific method mandated by 5280 and CAs vary in their
approach, best thing is for the CA to put the requested SKID from other
CA.

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Wednesday, June 23, 2010 7:01 PM
> To: Santosh Chokhani; Sean Turner; [e-mail]
> Subject: Re: [pkix] Possible new work item: additional methods for
> generating key identifiers
> 
> Santosh,
> 
> CSR and P10 is not the only valid input source, especially not in the
> case
> of cross certification.
> 
> I may for example want/need to cross certify a CA based on an existing
> certificate, not a CSR.
> 
> In such case I will validate the subject name (CA name) and PoP by
> trusting
> the original certificate and whatever other evidence I have that the
CA
> certificate is valid, such as a signed Trust service Status List (TSL)
> as
> defined in the ETSI standard TS 102 231 which use is mandated by the
> European commission for EU member states.
> 
> From the perspective of the cross certifying CA I will then have to
> inject
> the SKI of the original CA certificate into the cross certification
> process
> to make sure that there will be a SKI/AKI match when using that cross
> certificate.
> 
> This is not generally supported (even though OpenSSL do). Other tools
> insist
> on calculating the SKI using a fixed internal algorithm.
> In my case the following command will issues a cross certificate using
> openSSL:.
> 
> openssl x509 -in certToBeXcertified.pem -CAkey private/cakey.pem -out
> newCert.pem -CA cacert.pem -extfile extensions.cfg -clrext -days 365 -
> sha256
> 
> Where extensions.cfg in this example contains:
> 
> subjectKeyIdentifier=11982722E04AD543969AF3703D21D37085EACA9D #org SKI
> authorityKeyIdentifier=keyid:always,issuer:always
> basicConstraints = CA:true
> keyUsage         = critical, cRLSign, keyCertSign
> certificatePolicies    = ia5org,@xpolicy
> 
> [xpolicy]
> policyIdentifier = 2.5.29.32.0  #anyPolicy
> 
> 
> Other libraries I have tested do not allow setting the SKI value to
the
> one
> obtained form the original CA certificate.
> 
> In case further information is of interest I have made a demo video
> available from: http://aaa-sec.com/tsltrust/videos/demovideo.html
> 
> 
> /Stefan
> 
> 
> 
> 
> 
> On 10-06-23 11:15 PM, "Santosh Chokhani" <[e-mail]>
> wrote:
> 
> > Stefan,
> >
> > The KID is not being set to an arbitrary value.  You are honoring
> > extensions in P10 and CSR.  These structures have extensions
> precisely
> > for that purpose.
> >
> > A better approach would be to survey CA vendors to see if they do or
> do
> > not honor SKID in P10 and CSR request.
> >
> > I do not agree with the premise that CA products do not honor SKID
in
> > P10, especially those from another CA's P10/CSR.  There may be some
> who
> > do not honor KID, but the widely used ones do honor KID.
> >
> > We should focus on recommending or mandating that CAs honor the KID
> > requested as opposed to limiting number of KID options.
> >
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[e-mail]]
> >> Sent: Wednesday, June 23, 2010 11:10 AM
> >> To: Santosh Chokhani; Sean Turner; [e-mail]
> >> Subject: Re: [pkix] Possible new work item: additional methods for
> >> generating key identifiers
> >>
> >> Santosh,
> >>
> >>
> >> On 10-06-23 4:56 PM, "Santosh Chokhani" <[e-mail]>
> > wrote:
> >>
> >>> Stefan,
> >>>
> >>> They do not impact interoperability since the CA will honor the
> SKID
> >>> requested, specially by another CA.
> >>>
> >>
> >> It does impact interoperability since not all CA products and CA
> >> capable
> >> libraries allow SKID to be set to an arbitrary value.
> >>
> >>> Relying parties and issuers do not need to worry about the method
> >> used.
> >>> Relying parties just match the values and issuers just the value.
> >>>
> >>
> >> The relying party is affected if the certificate path he tries to
> use
> >> is
> >> rejected in his application due to AKI/SKI mismatch.
> >>
> >> So it MAY actually affect interoperability.
> >>
> >>
> >> Now let me clarify:
> >>
> >> 1) I do NOT defend any company or product that enforces AKI/SKI
> match
> >> 2) I'm not saying that we should NOT define the new SKI/AKI
> algorithms
> >> as
> >> suggested.
> >>
> >> I'm just recognizing the facts of reality and want to discuss the
> best
> >> way
> >> to deal with them.
> >>
> >> /Stefan
> >>
> >>
> >>
> >>>> -----Original Message-----
> >>>> From: Stefan Santesson [mailto:[e-mail]]
> >>>> Sent: Wednesday, June 23, 2010 10:51 AM
> >>>> To: Santosh Chokhani; Sean Turner; [e-mail]
> >>>> Subject: Re: [pkix] Possible new work item: additional methods
for
> >>>> generating key identifiers
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 10-06-23 4:29 PM, "Santosh Chokhani" <[e-mail]>
> >>> wrote:
> >>>>
> >>>>> Stefan,
> >>>>>
> >>>>> How do you derive from my post that I debate the AKID/SKID
> > matching
> >>>>> point?
> >>>>>
> >>>>
> >>>> Your statement: "I do not agree with your assertion about I-D
> >>>> conclusion
> >>>> being false."
> >>>>
> >>>> The debated I-D conclusion is: "The plethora of options does not
> >>> impact
> >>>> interoperability"
> >>>>
> >>>>> Actually, both the I-D and I recognize that point as immutable
> and
> >>>> that
> >>>>> is why the suggestions.
> >>>>>
> >>>>
> >>>> Still not sure how more standardized ways to calculate AKI/SKI
> >>> improves
> >>>> interop.
> >>>>
> >>>> /Stefan
> >>>>
> >>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Stefan Santesson [mailto:[e-mail]]
> >>>>>> Sent: Wednesday, June 23, 2010 10:02 AM
> >>>>>> To: Santosh Chokhani; Sean Turner; [e-mail]
> >>>>>> Subject: Re: [pkix] Possible new work item: additional methods
> > for
> >>>>>> generating key identifiers
> >>>>>>
> >>>>>> Santosh,
> >>>>>>
> >>>>>> It's not debatable whether mismatching AKI/SKI is an interop
> >> issue.
> >>>> It
> >>>>>> simply is.
> >>>>>>
> >>>>>> I can agree, that it should not be an issue, but it is. I have
> >>> first
> >>>>>> hand
> >>>>>> practical experience with exactly this issue.
> >>>>>>
> >>>>>>> For the activities I am involved with, for
> >>>>>>> the Bridge environments they had to add the capability to
their
> >>>>>> products
> >>>>>>> to be considered as meeting the requirements.
> >>>>>>>
> >>>>>>
> >>>>>> That is good news. I have encountered products/libraries where
> >> this
> >>>>> was
> >>>>>> not
> >>>>>> possible. I hope this will change.
> >>>>>>
> >>>>>> /Stefan
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 10-06-23 3:42 PM, "Santosh Chokhani"
<[e-mail]>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Stefan,
> >>>>>>>
> >>>>>>> While I do not see a need for separate RFC, most of material
in
> >>> the
> >>>>>> I-D
> >>>>>>> is not objectionable.  It is useful to augment 5280 (or modify
> >> it)
> >>>>> to
> >>>>>>> permit other hash algorithms as they become available in place
> > of
> >>> a
> >>>>>> new
> >>>>>>> RFC.  In that regard, I would rather revise 5280 and simply
> >>> replace
> >>>>>> SHA1
> >>>>>>> with any hash to accommodate hashes other than SHA 1 and SHA
> > 256.
> >>>>>>> Truncation of hash output is also a good idea.
> >>>>>>>
> >>>>>>> Some guidance in 5280 on honoring SKID in P10 or CSR of any
> form
> >>> is
> >>>>>> also
> >>>>>>> good.
> >>>>>>>
> >>>>>>> I do not agree with your assertion about I-D conclusion being
> >>>> false.
> >>>>>>> I-D statement is accurate.
> >>>>>>>
> >>>>>>> I also do not like the idea of achieving interoperability by
> >>>>> defining
> >>>>>> a
> >>>>>>> or very few method for KID calculation.  I rather CAs honor
> SKID
> >>> in
> >>>>>> CSR
> >>>>>>> extensions and most CAs do.  For the activities I am involved
> >>> with,
> >>>>>> for
> >>>>>>> the Bridge environments they had to add the capability to
their
> >>>>>> products
> >>>>>>> to be considered as meeting the requirements.
> >>>>>>>
> >>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: [e-mail] [mailto:[e-mail]] On
> >>>>> Behalf
> >>>>>>> Of
> >>>>>>>> Stefan Santesson
> >>>>>>>> Sent: Wednesday, June 23, 2010 5:26 AM
> >>>>>>>> To: Sean Turner; [e-mail]
> >>>>>>>> Subject: Re: [pkix] Possible new work item: additional
methods
> >>> for
> >>>>>>>> generating key identifiers
> >>>>>>>>
> >>>>>>>> Sean,
> >>>>>>>>
> >>>>>>>> I'm not convinced that we need more specified ways to
> calculate
> >>>> SKI
> >>>>>>> and
> >>>>>>>> AKI.
> >>>>>>>> On the contrary I think we may need less.
> >>>>>>>>
> >>>>>>>> Basically I think this conclusion is false:
> >>>>>>>>
> >>>>>>>>    The plethora of options does not impact interoperability
> >>>> because
> >>>>>>> key
> >>>>>>>>    identifiers are unilaterally generated by Certification
> >>>>>> Authorities
> >>>>>>>>    (CAs). Relying parties only compare and copy these values
> > and
> >>>>>> thus
> >>>>>>>>    are insulated (for the most part) from the specific
> >> mechanisms
> >>>>>> used
> >>>>>>>>    to generate them.
> >>>>>>>>
> >>>>>>>> So here is a real life example.
> >>>>>>>>
> >>>>>>>> Acrobat reader is one example of an application which,
despite
> >>>> what
> >>>>>>> RFC
> >>>>>>>> 5280
> >>>>>>>> suggests, requires SKI/AKI match in order to recognize a
path.
> >>>>>>>> A perfectly valid path with mismatching AKI/SKI values will
> not
> >>> be
> >>>>>>>> accepted.
> >>>>>>>>
> >>>>>>>> Combining this with the fact that lots of common CA
> >>>> implementations
> >>>>>>>> doesn't
> >>>>>>>> give you the choice to select SKI algorithm, neither allows
> you
> >>> to
> >>>>>> set
> >>>>>>>> an
> >>>>>>>> arbitrary value. OpenSSL is one of the few that allows you to
> >> set
> >>>>> an
> >>>>>>>> arbitrary value composed from an external calculation, but
> that
> >>>>>> seems
> >>>>>>>> to be
> >>>>>>>> the exception.
> >>>>>>>>
> >>>>>>>> This creates problem for cross certification where the
> > generated
> >>>>> SKI
> >>>>>>> in
> >>>>>>>> the
> >>>>>>>> cross certificate is getting less and less likely to match
AKI
> >> of
> >>>>>>>> issued
> >>>>>>>> certificates of the cross certified CA.
> >>>>>>>>
> >>>>>>>> Such paths will be rejected e.g. by acrobat reader.
> >>>>>>>>
> >>>>>>>> Since we do not require cryptographic strength, I would much
> >>>> rather
> >>>>>>>> make a
> >>>>>>>> strong recommendation to pick and use the most common SKI
> >>>>>> calculation
> >>>>>>>> defined in RFC 5280 rather than defining a whole bunch of new
> >>> ways
> >>>>>> to
> >>>>>>>> calculate SKI/AKI.
> >>>>>>>>
> >>>>>>>> This is simply yet one of the areas where theory and practice
> >>>> don't
> >>>>>>>> really
> >>>>>>>> align perfectly. Hence we should pick the option that creates
> >>>> least
> >>>>>>>> problems.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> /Stefan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 10-06-16 4:17 PM, "Sean Turner" <[e-mail]> wrote:
> >>>>>>>>
> >>>>>>>>> Greetings.  Steve and I have whipped up a short I-D that
> >>>> specifies
> >>>>>>>>> additional methods for generating key identifiers from a
> > public
> >>>>>> key.
> >>>>>>>>> The draft can be found at:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >
http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/
> >>>>>>>>>
> >>>>>>>>> I'd like to ask the WG to consider adopting this as a WG
> item.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>>
> >>>>>>>>> spt*
> >>>>>>>>>
> >>>>>>>>> * (with no hat on)
> >>>>>>>>> _______________________________________________
> >>>>>>>>> pkix mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/pkix
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> pkix mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/pkix
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> pkix mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/pkix
> >>>>
> >>>
> >>
> >
>