Speaking as regular ol' member.
On Apr 21, 2014, at 11:55 PM, Geoff Huston <g...@apnic.net> wrote:
======================
>>Except that the signed object signature algorithm OID will be
>>rsaEncryption which I think is still PKCS#1v1.5, but is not in section
>>5 of rfc4055.
>
>
>I am unsure what you mean here. Perhaps if you send what you think the
>text should say it would be helpful.
The comment is about the correctness of the reference. But that
should not have an impact on implementation, so I withdraw the
comment.
=================
>what about:
>
>"The locations where algorithm object identifiers appear are:"
Works for me.
======================
>I think this was a failing in RFC6485 itself.
>RFC6487 has forward pointers to RFC6485 in the algorithm section for
>PKCS , but the text in RFC64845 refers to "certificates, CRLs and
>signed objects".
>
>Do you have alternative text to suggest here?
>
Defending RFC6485: RFC6485 only had one OID to talk about, so any
reference to an OID could be assumed to be that one OID. So the
choice for cert requests might not have been direct in RFC6485, but
there was no ambiguity.
But, yes, with the added mention of new OIDs, the text retained from
RFC6485 is no longer clear about implementation of cert requests.
I suggest the following alternative text would make the choice clear.
The changes add cert requests where the choice for certs and CRLs is
mentioned.
From:
* The signature algorithm used in certificates, CRLs, and signed
objects is RSA Public-Key Cryptography Standards (PKCS) #1
Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from
Section 5 of [RFC4055].
To:
* The signature algorithm used in certificates, CRLs, signed
objects, and certification requests is RSA Public-Key Cryptography
Standards (PKCS) #1 Version 1.5 (sometimes referred to as
"RSASSA-PKCS1-v1_5") from Section 5 of [RFC4055].
From:
* The hashing algorithm used in certificates, CRLs, and signed
objects is SHA-256 [SHS] (see note below). Hashing algorithms
are not identified individually in certificates and CRLs, as
the identity of the hashing algorithm is combined with the
identity of the digital signature algorithm.
To:
* The hashing algorithm used in certificates, CRLs, signed
objects, and certification requests is SHA-256 [SHS]
(see note below). Hashing algorithms are not identified
individually in certificates, CRLs, and certificate requests
as the identity of the hashing algorithm is combined with
the identity of the digital signature algorithm.
From:
For generating and verifying certificates, and CRLs the hashing and
digital signature algorithms are referred to together, i.e., "RSA
PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The
Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST
be used in this case.
To:
For generating and verifying certificates, CRLs, and certification
requests, the hashing and digital signature algorithms are referred
to together, i.e., "RSA PKCS#1 v1.5 with SHA-256" or more simply "RSA
with SHA-256". The Object Identifier (OID) sha256WithRSAEncryption
from [RFC4055] MUST be used in this case.
========================
A couple of typos in the new section 8 explaining the changes:
From:
Section 2 of [RFC6485] specified a single signature algorithm (SHA-
256)
To:
Section 2 of [RFC6485] specified a single signature algorithm (RSA
PKCS#1 v1.5)
(I'm guessing here what you mean, but I'm pretty sure the text did not
mean SHA-256 is a signature algorithm. It could also be that the
text meant:
To:
Section 2 of [RFC6485] specified a single signature algorithm (RSA
<or "RSASSA-PKCS1-v1_5"> and a single hash algorithm (SHA-256)
or ... something else?)
This section is an explanation of the change, so it is intended for
the IESG, and is not crucial to implementation. I think it would be
better to change to say what you mean, but I can accept it.
There's also this typo:
From:
This document changes Section 2 of [RFC4055].
To:
This document changes Section 2 of [RFC6485].
That also is not crucial to implementation, but it might confuse the
secretariat to have this text claim that the draft updates 4055. If
anyone notices.
==========================
>> I presume accepting sha256WithRSAEncryption is backward compatibiilty
...
>
>I am already hopelessly confused by this situation, and I'm in no
>position to answer this.
No one else has expressed any concern over the backward compatibility,
so I withdraw the comment.
==============================
Then there's this new bit, which I noticed in the midst of checking
what was needed for the certificate requests.
In Section 2, the text says
In a certification request, the OID appears in the PKCS #10
signatureAlgorithm field [RFC2986], or in the Certificate Request
Message Format (CRMF) POPOSigningKey signature field [RFC4211].
RFC4211 says that the POPOSigningKey is:
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
I'm pretty sure the text should say the OID goes in the POPOSigningKey
algorithmIdentifier field, not the POPOSigningKey signature field.
[[While this looks clear to me, the comment could use some review by
someone comfortable with ASN.1 overloaded and inconsistent field
names.]]
That text is in the original RFC6485 and it has no relationship with the
problem with the OID choice in CMS, the reason for this bis.
However, if true, this has implementation impact, so I think this
should be considered at some point.
*IF* people agree that this is wrong, do the authors have any
problem with changing the text in this bis?
FROM:
Message Format (CRMF) POPOSigningKey signature field [RFC4211].
TO:
Message Format (CRMF) POPOSigningKey algorithmIdentifier field
[RFC4211].
--Sandy, speaking as regular ol' member
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
